1. Field of the Invention
The present invention relates generally to sending data on a token bus and, more particularly, to a method for reliable real-time detection of which units are present on an ARCNET.
2. Prior Art
A token bus operates as a shared medium. Only the unit which has the “token” (alternatively referred to as an “invitation to transmit” (ITT)) is allowed to send data on the bus. When a unit (node) has transmitted any data it has to send, it sends the token to the next unit in the token rotation (i.e., transmits a token with the destination address of the next unit). Inherent in a token bus system is the ability to know which units are present on the bus by monitoring the addresses of the tokens being sent during each token rotation with a bus “snooper” circuit. Here, the snooper circuit is assumed to reside in a system controller unit (SCU).
The ARCNET LAN protocol, as described in ANSI Standard 878.1, can be summarized as follows. To build the token rotation list, which must occur whenever a new unit is added to the bus, the new unit “jams” the bus by sending a long pattern guaranteed to create a lost token situation. Once this situation has occurred, the bus will be idle until the unit with the highest address times out. (The time-out value is a function of a unit's address value.) This unit then attempts to find the unit with the next higher address value (which, due to the modulo 255 arithmetic is actually the unit with the lowest address value). This unit will in turn try to find the unit with next higher address value, and so on until each unit has determined which unit has the next highest address to its own. The token rotation is now established and each unit retains only the address of the unit to which it sends tokens. The method by which a unit finds the unit with the next higher address value is discussed further below in the discussion of units being removed from the bus.
Under normal, steady-state operation, a unit receiving a token sends a token to the next unit in the list if it has no data to send. If the unit receiving a token has data to send, it first queries the destination with a Free Buffer Enquiry (FBE) message. If the destination unit has buffer space available to receive a packet, it responds with an ACK message, and if its receive buffers are currently full, it responds with a NACK message. If it receives an ACK to the FBE, the unit with the token sends its packet and then sends the token to the next unit. If it receives a NACK message, it sends the token to the next unit immediately. (The unit will attempt to send the message again the next time it has the token.) Each unit has a finite amount of time to respond to a token by either initiating a packet transmission or sending another token. The same response time is required to respond to a FBE. If a unit fails to respond to a FBE, the sending unit assumes that this unit is not in the system and quits attempting to send that packet.
If a unit fails to respond to the token, the sending unit assumes that this unit has been removed from the system. It then attempts to find the next unit in the rotation (i.e., the unit with the next higher address value). This search for the next unit is done by incrementing the token destination address by ‘1’. If the unit at that address responds to the token, the sending unit stores that address as its token destination. If the unit at that address fails to respond, the unit again increments the address and sends another token and continues the process until the next unit is found.
Noise on the ARCNET bus can cause the following problems with token passing:    1) If noise corrupts a token, the destination will not recognize it and hence will not respond. The sending unit will treat this situation the same as if the unit was removed and the original destination unit will be deleted from the map. Eventually, the original destination unit will experience a time-out due to not receiving a token and will force a new-unit bus reconfiguration.    2) Noise after a token is interpreted as a response to the token. This case creates a lost token situation that is covered under normal bus reconfiguration.
The first case is the one that causes the difficulties for a token map snooper circuit since it is impossible to distinguish this event from an actual unit removal/failure. If fast real-time response is not required, the snooper can simply wait until the deleted unit causes a reconfiguration and rejoins the bus. In telecommunications systems that rely on the snooper bus map to trigger unit protection switching from a failed/removed working unit to a standby protection unit, waiting for reconfiguration is not an option. The deleted unit will wait 840 ms before triggering the reconfiguration and the protection switch must be completed within 60 ms (10 ms for detecting the removal plus 50 ms to complete the switch).